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Method and system for single sign-on user access to multiple web servers 



(57) Methods and systems for single sign-on user 
access to multiple web servers are provided. A user is 
authenticated at a first web server (e.g., by user name 
and password). The first web server provides a web 
page to the user having a service selector (e.g., a 
hyperlink comprising the URL of a second web server 
offering the service indicated by the selector). When the 
user activates the service selector, the first web server 
constructs and transmits an encrypted authentication 
token (e.g., a cookie) from the first web server to a sec- 
ond web server via the user client. The first and second 
web servers share a sub-domain. The authentication 
token comprises an expiration time and is digitally 
signed by the first web server and is authenticated at 
the second web server. Upon authentication, the sec- 
ond web server allows the user to conduct a session at 
the second web server. 



a. 

LU 



Printed by Xerox (UK) Business Services 
2.16.7 (HRS)/3.6 



KXO. <EP 1089516A2_I_> 



35 



40 



45 



50 



55 



EP 1 089 516 A2 

Description 

I- Cross Reference to Related Application 

5 [0001J This patent application claims priority to co-Dendinn I initari <ztn+ d - . 

60/155.853, entrtled "Method and System for Sin^i^X r ^^r TT^ AppNcati ° n Serial No 

tember 24, 1 999, which is hereby incorporated X^^S. " °' Web SerVGrS '" fi,ed Se P' 

II. Field of the Invention 

70 

[0002J The present invention relates generally to the fi^lri nt - 

the present invention relate generally to a method and I sv^l f COmmerce - More Particular, embodiments of 

servers. V meth ° d and for Priding single sign-on user access to multiple web- 

's III. Background of the Invention 

■n order to aggregate functionality to the auman^^^^^Z?* VT™ aPP ' iCati ° n se ™- 
may wish to allow their customers access to such an aggregated tunc Z,» e h nt ' t,esSuch 30 6ntity or 9 rou P ° f entities 
themselves once, and then being able to use differenfseSs 2 Z J °" ° n ' y ° nCe ' ^ authenticating 

enfities within the group of entities, observers of 

2SL J! a-^f^ - customer, via a web browser, a set of 

such as a UNIX platform, an NT platform, 2 som 'other woe!? Iti * T T™* emp '° y different P ,atfo ^, 
different organizations within the group o entries TtZ Sol mtT k P ' atf0rm haVe been c °^ructed by 
any event, an essentia, problem is how to a.low the culm^r to Won be ^ P rovided * third-party providers. In 
different servers without requiring the customer toXnT^ZTel^^S * T™"** these 
server. y on eacn ana every time he or she goes accesses a different 

[0005] Conventional products attempting to address this nrnhi sm ^ 
formance and cost. In some such products. It is neceJSrvTo rZnl Z TT' b ° th in terms of P«r- 

not support crossing organizational boundaries o Ztm7t ^TZn^ T ° thers ^" P^ucts do 

tern for single sign-on user access to multiple web served such a , h T ' * ****** * 3 methods and *Ys- 
that overcome such disadvantages and tha' prSe ^ o^advantages " ** M ™ 8 Mg 

IV. Summary of the Invention 

[0006] The present invention provides methods anrt c^,ot^ * 

such as a federation of web servers .hrt^^^^2^ ^ ™ a °° M8 «° mU ' tiple web 
a first web server (e.g.. by user name and passwo^ ^eT^T^ZZT^ * '* auth ^«cated at 
service selector (e.g.. a hyperlink comprising the URL of J T.ZTh Z P ** * W * b page t0 the user ha *"9 * 
selector). Upon activation of the selector ^use the firs web s - ** S6rVice indicat * d by L 

encrypted authentication token (e.g.. a cookie) from the fi. ZeTse^Z ^ ^ 3nd transmits an 

encoding is emp.oyed to encrypt and sign the authentic^ ^^^T^^T^^^ Wel ^ URL 
domain. The authentication token comprises an expiS time ^ pTJt, r * "** Share a sub " 

cated at the second web server and URldeeo<iSStoS U^n iTTT" **" * 6Xamined and au,he "«" 
passed, the second web server allows the user to conXTs^ JZT T' T " ^ eXPifati ° n time haS not 
[0007] In another embodiment a method fnr J„ 1 he Sec ° nd web server - 

first and second web server 5S£ ^2SST?pSSS Tan^T? 3 fedefati ° n * ^ — - a 
user at a computing device to access a first web served Tfte fedlt emb ° d ' ment ' the method com P" s ^ a »<>wing a 
puting device, authenticating the user with J^^^Z^^r?*, ™ 3 "* br0WSer ° f the «^ 
Won. by the first web server, and allowing the user to con^t ,n,0fTTiat «°n. '"eluding at least a user identifica- 

first web server carries out the functton.C^^^ "T S *™ the ses -". the 

ond web server, and receiving a selection by the user of the ^ionS « V™*™*^ offered ^ a t 'east a sec 
Upon receiving a selection, the first web seL creates an a I?„ T f t ™ ** S *°° nd Web Server - 
identification and with a pre-defined token exp^^VwTse^i TT " ^ ^ a ' ,east the — 

-authentication tokenbythefirstwebse^Yemb^^^^ 
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authent.cat.on token with the shared sub-domain name by the first web server, sending the digitally signed authentica- 
tion token to the web browser of the computing device by the first web server, redirecting the web browser to the second 
web server by the first web server, and sending the authentication token to the second web server by the web browser 
The second web server decrypts the authentication token, confirms a match with the digital signature of the first web 
server, checks the pre-defined expiry of the authentication token by the second web server, and allows the user to con- 
duct a session with the second web server if within the pre-defined token expiry. 

[0008] In another embodiment, a method of single sign-on for multiple web servers, comprising receiving log-in 
data from a user in a first server, providing the user with a service selector, receiving an indication that the user selected 
the serv.ce selector, constructing an authentication token comprising profile data associated with the user encrypting 
and signing the authentication token, redirecting the user to a second server, transmitting the authentication token to 
the user, rece.v.ng the authentication token in the second server, verifying the authentication token in the second server 
and allowing the user access to a service provided by the second server. In one such embodiment, the authentication 
token comprises a cookie and further comprises expiration time data. 

[0009] It is a feature and advantage of the present invention to provide a method and system for single siqn-on user 
access to a federation of web servers that allows users already authenticated on a web site, such as a financial institu- 
tion's web site, to have access, for example, to a service provider's web site without having to be re-authenticated via 
provision of a valid name and password. 

[0010] To achieve the stated and other features and advantages, an embodiment of the present invention provides 
a method and system which enables single sign-on access for a user to a federation of web servers that allows user 
authentication at an entity's web site server, selection of a service provider URL. and passage of an authentication 
token by the entity's web site server to a service provider's server that contains sufficient information to enable the serv- 
ice provider's server, for example, to recognize the user as a valid service provider user and to provide the user with 
customer specific information. 

[001 1] Additional objects, advantages and novel features of the invention will be set forth in part in the description 
which follows, and in part will become more apparent to those skilled in the art upon examination of the following or 
may be learned by practice of the invention. a ' 



V. Brief Description of Figures 
30 [0012] 

FIG. 1 shows an embodiment of a system according to the present invention. 

FIG. 2 shows a flow diagram describing a process according to the present invention carried out in the system 
shown in FIG. 1. 

FIG. 3 shows a visual depiction of web pages associated with web servers of the system shown in FIG 1 
FIG. 4 shows a flow diagram describing an alternative process according to the present invention carried out in the 
system shown in FIG. 1. 

VI. Detailed Description 



!E23L , n 1 T a " embod,ment of a svstem according to the present invention. A brokerage firm web server 
(BFWS) 30 includes a brokerage firm web site 32. The brokerage firm web server 30 (and likewise the brokerage firm 
web site 32) .s .n communication with the Internet 20. Likewise, a bank web server 40 includes a bank web site 42 The 
bank web server (BWS) 40 (and likewise the bank web site 42) is also in communication with the Internet 20 A cus- 
tomer 5 of both the brokerage firm and the bank is shown. The customer 5 has a user name and password to access 
both the brokerage firm web site 32 and the bank web site 42. The customer's personal computer 10 having a web 
browser such as Microsoft Internet Explorer or Netscape Navigator (a client) is in communication with the Internet 20 
as well. The customer 5 uses the customer's personal computer and browser 10 to communicate with the web servers 
30. 40 via the Internet. Herein, the term customer is used in many instances to indicate the client 10 as used by the 
customer. In addition to network communication facilities and other aspects, the brokerage firm web server 30 and the 
bank server 40 comprise programming to carry out the functions described herein. 

[001 4] FIG. 2 shows a flow diagram of steps carried out in the system shown in FIG. 1 . The customer 1 0 points the 
customer's browser to the brokerage firm web site 32. The customer 1 0 logs into the brokerage firm web srte 32 using 
the customer's correct user name (or user identification) and password for the brokerage firm web site 32 and is 
authenticated by the brokerage firm web server 30. Once the customer logs into the brokerage firm web site' 32 the 
web site 32 presents the customer 1 0 with a welcome page from the web site 32. Once logged in. the customer 1 0 may 
examine the customer's brokerage account information, portfolio, investment information, and the like 
[0015] FIG. 3 shows a graphical depiction of the system shown in FIG. 1 , including the welcome page 100 from the 
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brokerage firm web site 30 provided to the customer 10 once the customer logs in at the brokerage firm web site 30 
The welcome page 100 shown in FIG. 3 includes a service selector in the form of a hyperlink shown as 'bill payment" 
102. The brokerage web site offers its customers the ability to pay bills. 

[00161 Referring again to FIG. 2. the customer 10 requests bill payment 50 by clicking on the 'bill payment" hvper- 
l.nk 102. The brokerage firm web server 30 itself does not handle the process of bill payment but the server 30 is pro- 
grammed with the knowledge that the bank web server 40 handles such a process. The hyperlink 1 02 includes the URL 
of the bank web srte 42. Upon detecting the request of bill payment, the brokerage firm server 30 builds an authentica- 
tion token 52. An authentication token comprises an object (or data) that can be passed between cooperating servers 
A function of an embodiment of an authentication token is to convey the necessary information from a primary (or first) 
server to a secondary (or second) server to allow the secondary server to skip the sign-on process that would otherwise 
be necessary and required. Once a primary server establishes a session for a user, a cooperating secondary server 
cTagakf 68 * ^ authentication token from the primary server can establish a session without having the user sign 

[0017] In the embodiment shown in FIG. 1 , the brokerage f.rm web server 30 builds an authentication token (or 
access token) comprising user identification data (or profile data) and expiration time data (token expiry) 52 The profile 
data comprises user identification data comprising a customer identification number that uniquely identifies the user to 
the secondary server. In the shown embodiment, the token also include a list of accounts of the customer Expiration 
time data comprises data reflecting the time after which the authentication token is invalid. In the embodiment shown 
the time is in Greenwich Mean Time (GMT). In other embodiments, the time may be in Universal Time Expiration time 
may be set by the primary server at any desired time, though in most embodiments the expiration time is a relatively 
short time, e.g., three to twenty minutes, from the time at which the authentication token is created. In the embodiment 
shown, the expiration time is set at fifteen minutes from the time the authentication token is created Note that it is 
important for the servers exchanging such authentication tokens to maintain correct or synchronized clocks The use of 
expiration time is used to create a single-use, perishable token. 

[0018] In the embodiment shown, the authentication token built comprises a cookie with profile data of the cus- 
tomer 5 and an expiration time of fifteen minutes from the creation time of the token. Authentication tokens may also 
comprise URL strings or other data that may be passed between servers. The profile data of the customer includes a 
customer identification number for the customer 5. The brokerage firm web server 30 includes a data storage system 
(e.g., a hard disk drive) that has customer identification numbers associated with log-in user names used by customer's 
of the brokerage firm web server 30. These numbers were agreed upon previously by the administrators of the servers 
30, 40. In the embodiment shown, a customer is associated with a customer identification number. In the embodiment 
when the customer requests bill payment 50. the server 30 retrieves, from the data storage system, the customer iden- 
tification number for the customer 5. This customer identification number retrieved is used in the profile data used to 
build the cookie 52. 

[0019] In another embodiment, various customer identification numbers are associated with various secondary 
servers. When the customer requests a service provided at a secondary site (or to be transferred to a secondary site) 
the primary server detects the request, determines the secondary site, and retrieves, from the data storage system the 
customer identification number for the requesting customer that is associated with the secondary site to which the cus 
tomer will be directed for bill payment services. 

[0020] Referring again to FIG. 2, the server 30 also selects the secondary server recipient name 54 The server 30 
does so by examining the request made by the customer and determining the name / address of the appropriate sec 
ondary server to handle the request. In the embodiment shown, the server 30 examines the "bill payment" request 
made by the customer. In the present embodiment, the examination comprises determining the Uniform Resource 
Locator (URL) associated with the "bill payment" hyperlink. The web page file associated with the welcome page 100 
includes the URL associated with the "bill payment" hyperlink, and the server 30 selects this URL 
[0021 ] The seiver 30 then signs and encrypts the cookie 56. A digital signature associated with the brokerage firm 
seiver 30 .s applied to the cookie 56 by the server 30. Preferably, the server 30 comprises public key encryption soft- 
ware capable of encrypting, digitally signing, and authenticating electronic transactions across applications arid serv 
ers. In the embodiment shown, the Entrust/PKI 5.0 software package, with its associated application programming 
.menace (API) library, available from Entrust Technologies. Inc.. Piano, Texas, is used to sign the cookie using a public 
key encryption system. In the embodiment shown, the cipher used is the Triple DES (Data Encryption Standard) 
encryption algorithm system, the encrypted cookie uses privacy-enhanced mail (PEM) headers and signing uses the 
Secure Hash Algorithm (SHA-1 ) to create the message digest (or hash value) in signing. The Triple DES system is used 
to encrypt the authentication token (the cookie), and a PEM header and SHA-1 digest is included 
[0022] A digital signature associated with the server 30 (in the form of a signed-encrypted string) applied to the 
cookie allows a secondary server to verify that the authentication token was created by the brokerage firm server 30 
Further, the signature allows a secondary server to detect any modification or corruption of the authentication token' 
The digital signature is applied and encrypted by the server 30. 



EP 1 089 516 A2 

[0023] In the embodiment shown, the cookie is created and kept on the browser 10 of the user 5 using a header 
entry ,n the response page, and the header entry is structured as follows: Set-cookie; name=value- expires-date tfrne 
doma.n.doma.nname; path=path ; secure. The path value comprises a specific directory, and the domafnname vie 
preferably ,s a common sub-domain (discussed further below). In an embodiment, the authentication token JhTcoc Me) 
5 ,s non-pers,stent andw.ll not be written to disk on the customer client ,0. In such an embodiment, an exp revalue 1 
not necessary, and the cookie will be deleted by the receiving server immediately after receipt 

L°af follows^ 6XamP,e ° f 3 Strin9 C ° mpriSing COOkie ~"<*°n according ,o an embodiment of the present invention 

10 VERI1 EXPDT1 199905051 32540IICT\CUSTIAFIEXISTIICIDI576001 00056005023 4II 

FCIDI0IITAI2IIANMI001 0000001 IIRTNI099IIANAIMy wife's 
CheckingllABI237600IIANMI0010000002IIRTN009IIANAIMy 

checkingllABI24556. The example is in the following format: Tag1 TagValuel Tag2 TagValue2 Tag3 TagValueS .... 

15 l s a JZTZ^::r drK tass and their 139 va,ues may vary accordins * ^ as 

[0026] Tags in the example shown, their value, and a descri P t,on is shown in the following table: 
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Tag 


Tag Value 


Description ~~ — » 


VER 


1 


Version of cookie system being used (current version is 1 ) " 


EXPDT 


Date / Time 


ITnr^ date t,me th3t the authentlc ^ion token expires. Format: CCYYM- 
MDDHHMMSS. 


CT 


CUST FC 


Customer Type. CUST= regular customer. FC= Customer Representative Used to 
activate view-only mode. 


AF 


NEW / EXIST 


New or existing customer indicator. 


CID 


integer 


Customer Identification Number 


FCID 


Alphanumeric 


Identification number for customer service representative. If the user is a regular cus- 
tomer, do not set FCID (i.e., set to 0). 


TA 


Integer 


Total Number of Accounts of customer 


ANM 


Integer 


Account Number "~~ "~ — 


RTN 


Integer 


Routing transit Number - maps to prod-type-cd 


ANA 


Alphanumeric 


Account nick name — 


AB 


Integer 


Account Balance in cents (i.e. $10.50=1050) 



45 



SO 



55 



[0027] In the embodiment shown, the order of tags is not significant, except for ANM ANA AB whi^h nro .m 

ered a tuple and are grouped together as shown above. Also, in the embodiment shown the V E R EXPDT c e 
requ.red tags. Other tags that may be used in other embodiments include the following: AG (agency oT' SnolZ 
name that employs the user). FN AM (first name of user), and LNAM (last name of user) corporation 
[0028] The AF tag allows the bank server 40 to determine if an "Activate User" message should be sent to a ttans 
act.on processing system (TPS). Preferably, if the brokerage firm web server 30 cannot determine whether a cus omer 
.s new or already enrolled with GTPS. the server 30 sets the AF tag to NEW. In addition, the broker^ firm web se'e 

value d^teZeT ™ * " CheC ^ 9 ' ^ * nd *~ pM ~ de ba ~* o7S 

[0029] The brokerage firm server 30 then URL encodes (also called URLEncode) the constructed coold* « 

UH^ZlllT 09 th Tr- br ° kerfimi — the formatted 5 noX^^ t a 
URL-encoded format. In one embod.ment, the URL encoding encodes the string using the URL escape syntax which 
comprises a three character string (%nn) specifying the hexadecimal code for a character. This synt J 1 used t Thide 
characters that may be otherwise significant when used in a URL. The URL encoding 58 carried out by the brokerage 
finm web server 30 results ,n an encoded, signed, and encrypted string suitable for writing in a cookie, and M sZ 
is included in the cookie built by the server 30. 9 
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[0030] The brokerage firm web server 30 then sends a redirect command (or redirect page) with the URL encoded 
cookie (the authentication token) in a set^ookie header to the customer client 60. The redirect command includes the 
URL of the web site associated with "bill payment" 42. The customer client 10 receives the redirect command and the 
uhl encoded cookie constructed by the brokerage web server 30. 

[0031] The customer client 10 connects with the bank web site 42 via the Internet 20 and sends the cookie to the 
bank web server 62. In the embodiment shown, the authentication token is transmitted in a Secure Sockets Layer (SSL) 
session. Further, in the embodiment shown, on receipt of the redirect command, the customer client 1 0 opens a second 
browser window requests a download of the home page at the URL of the web site 42 (or the page designated in the 
URL) recedes the page of the web site 42 from the bank web server 40, and displays the page in the window* An 
embodiment of such a window 1 10 and page is shown in FIG. 3. The cookie received by the customer client 10 from 
the brokerage firm web server 30 is sent by the customer client 1 0 to the bank web server 40 

[0032] The bank web server 40 receives the cookie from the customer client 1 0. The bank web server 40 decodes 
the encoded, signed and encrypted string built into the cookie by the brokerage firm web server 30 into a signed 

fhTZs H S,r '^ k umn^ emP '° yS URL DeC ° din9 ( ° r URLDec ° de > ™thods ^ the embodiment shown In 
the embodiment shown, URL Decoding is employed to convert the URL encoded string in the cookie to plain ASCII for 
examination by the bank web server 40. The bank web server 40 and the brokerage firm web server 30 previously 
exchanged public -private key decryption information. y 
[0033] Once the string is decoded, the bank web server 40 decrypts and verifies the cookie (including the signed 

Z7TT 9 f T ' S r W d H COd l d) 66 ' n embodiment sh ™ n . comprising public key encryption soft^ 

ware capable of decrypting and authenticating electronic transactions across app.ications and servers is used by the 
bank web server 40 to do so. One example of such software is the Entrust/PK! 5.0 software package, with its associated 
application programmmg interface (API) library, available from Entrust Technologies Inc Piano Texas 
EUfi! ^.fTT 40, USin9 SOftWare mentioned ' determines whether the digital signature associated 

tT T r ^ S ' 9natUre d06S V6rify ' thS bank W6b SGrver 40 ^ the a «*"Ved sign-on and 
re-d.rects the customer client 10 to a web page on the brokerage firm web server 30 indicating an error and sign-on 
failure 70, resulting in a failed sign-on attempt 72. In another embodiment, if the signature does not verify the bank web 
server 40 rejects the sign-on and sends a web page indicating an error and sign-on failure to the customer c.ienM 0 In 
an embodiment, if the signature does not verify,, the bank web server 40 also sends a message indicating such failure 
to the brokerage firm web site 30, e.g.. an e-mail message. 

[0035] If the signature verifies, the bank web server 40 examines the Certificate Authority (CA) name associated 
with the cookie 74. The server 40 compares the CA name associated with the cookie (i.e., the CA used with the CA 
name expected, as recorded in a registry file in the bank web server 40). If the CA name is not the one expected the 
bank web server 40 re-directs the customer client 1 0 to an error page on the brokerage firm web server 70 and the sign 
on attempt fails 72, as described above. 9 
[0036] If the CA name is the CA name expected, the bank web server 30 next if the sender's name is correct 76 In 
doing so. the bank web server 30 determines whether the Common Name (CN) associated with the cookie (i e the 
name being certified -the name used by the brokerage firm web server 30) is an authorized name. In so determining 
the bank web server 40 compares the CN associated with the cookie with a file containing authorized names in a data 
regis ry ,n the bank web server 40. If the CN is not the one expected, the bank web server 40 re-dfrectsThe cus^t 

Sn£, ^ if! 6 ™ Pa9e ° n br °lT 9e firm WCb SerVer 70 and the si 9 n -° n f ai's 72. as described above 

v wl ,S C Zt ' ' CN iS a " authori2ed name, the bank web server 40 extracts profi.e data from 

the cook,e and begins a bill-payment session 78. In the embodiment shown, the server 40 parses the clear text data 
assocated with the cookie (clear text refers to the information that is not encrypted) 78, and examines the exoiration 
time data in the cookie (not shown). If the expiration time has passed, the bank web server 40 re-directs the customer 
client 10 to an error page on the brokerage firm web server 70 and the sign-on attempt fails 72, as described above 
The clear text data includes profile data (e.g.. customer identification number). If the expiration time has not passed the 
web server 40 begins a bill payment session using the session and profile data 78 by sending the customer client' the 
web page 1 10 of the bank web site 42 that is shown in FIG. 3, and the sign-on is successful 80 The customer clfenno 
receives the web page 1 00 and proceeds with the bill-payment session with the bank server 40. In an embodiment the 
authentication token (cookie) is then discarded or destroyed by the web server 40 

[0038] In an alternative embodiment, the system reflects a service associated with a user's employee One such 
embodiment is shown in FIG. 4. In the embodiment shown in FIG. 4, the process of this alternative embodiment gener- 
ally proceeds as that discussed above, with exceptions discussed below. The embodiment shown employs a primary 
server comprising a central web server having a central web site (not shown). The central web site comprises a web 
site at which the customer client 1 0 may request various services by clicking a hyperlink. 

[0039] Referring to FIG. 4, the customer5 signs on to the central web site 49, and the process 150 152 154 156 
1 58, 160. 1 62. 1 64, 1 66, 1 68. 1 70, 1 74, continues in a manner like that described above in relation to steps 50 52 54' 
56. 58. 60. 62. 64. 66. 68. 70, 74 shown FIG. 3, with the central web server serving as the primary server (the brokerage 
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web sender served as the primary web server in the embodiment shown in FIG. 2) until the step shown as item 77 
occurs. The primary server includes the following, additional taas in the cookiP- ap Lon 

employs the r ,. FNAM „„s, name „, user, end LNAM C^ZT^^^X"" 
4 eompnses the seconder server, and In the embodiment shown comprises the bank rt™«»«l h . 
s web serve, 40 determines that the senders CA Is correct, the web serve, 40 dMearZL^lZ^.^ , T 
empire, has srgned op »» the servloe provider aeeoclahod wlth the secon^Te™, £ ^0^.™, 4^? 

employers. „ the nam. ^Z ^Z^ZTZ ^VZ^^^r ^ * °' 
,o central web site to, an emr, URL 70 me web setver 40 r.-direos the customer clr.nt 1 0 back to the 

CL :ITJ7J^ pn — * e *"** 9 ~ 

- prjLoned:::^ 

[0044] In embodiments, multiple primary servers are emnlnupH Tho n ,i m o« 
~--os,mey„ra^ 

compares the domain attributes of the cookie with the Internet domain name oTthe host » themi^M " '.T 
the cookie will go through path matching to see if i, should be sent TaTmatchino- mil! Z , „ ' 
matched against the tail of the fully qua.ified domain name of the host Fo examn 2 » n t^™ '* 

wou.d match host names "yyyy.xxxx.com' as well as '^^^^^T""- " ^ 

the user interacts has a domain name of qqqq.ym*^^ 

ssss.rrrr.yyyy.com, may share cookies in such an embodiment In an embodiment tZ id ! u ° f 
server associated with the primary server either (1) maos the slnnZT 5 P ° lntenn the d ° main name 

designated .P address associated with ^^^^^^ ^ISST* * * P ~ 
associated with the secondary server for resolution. 4 ° 3 ° NS name server 

[0047] As discussed above, certain embodiments of the present invention employ URL Encode and URI n«wio 
S^K^T" ' ra9ment ^ " MiCrOSOft C++ 6 0 *-* « "-P.e -i^^^ 
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// 

s // URLEncode converts some characters to %xx format for sending 

// in a URL or writing to a cookie 

// 

w void URLEncode (BYTE* szDecoded, BYTE* szEncoded) 

{ 





BYTE* pszInPtr = szDecoded; 




15 


BYTE* pszOutPtr = szEncoded; 




BYTE inch; 




20 


while ((inch = *pszInPtr++) != '\0') 


25 


{ 






if( (inch < 32) || 


(inch > 127) 




(inch = = '=') || 


(inch = = '?•) 


30 


(inch = ='&') || 


(inch = = *+') 




(inch = = '%') || 


(inch = = '-') 




(inch = = ':') || 


(inch = = ';') 


35 


(inch = = ',')) 





{ 

*pszOutPtr-M- = '%'; 

40 

spnntf((char*)pszOutPtr, "%02x", inch); 
pszOutPtr += 2; 

} 

45 

else 

*pszOutPtr++ = inch; 

so } 

*pszOutPtr++ = '\0\;; 

} 

55 

[0048] The following code fragment shows the implementation of URL-Decode by as se 
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// 

// URLDecode converts characters in the %xx format back to their 

values 

// 

void URLDecode (BYTE* szEncoded, BYTE* szDecoded) 
{ 

BYTE* pszInPtr = szEncoded; 
BYTE* pszOutPtr = szDecoded; 
int inch; 

while ((inch = *pszIntPtr++) != '\0') 
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{ 

5 if(inch = <%') 

*pszOut?tH-+ = (unHex(pszInPtrM-) « 4) + 
unHex(*pszInPtr++); 

io else 

*pszOutPtr+-t- = inch; 

} 

*pszOutPtr++ = '\0'; 

} 

int unHex (BYTE hexChar) 
{ 

if ((hexChar »= '0') && (hexChar <= '9')) 

return hexChar - '0'; 
if ((hexChar >= V) && (hexChar <= T )) 
return hexChar - 'a' +■ 10; 
30 if ((hexChar >= 'A') && (hexChar <= 'F')) 

return hexChar - 'A' + 10; 
return 0; 

} 



15 



20 



25 



35 



[0049] Those of ordinary skill in the art will recognize that there are a variety of code fragments useful in carrying 
40 out such steps. Further, a variety of programming languages may be used. 

[0050] Various embodiments of the invention have been described in fulfillment of the various objects of the inven- 
tion. It should be recognized that these embodiments are merely illustrative of the principles of the present invention 
Numerous modifications and adaptations thereof will be apparent to those skilled in the art without departing from the 
spirit and scope of the present invention. 
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Claims 



1. A method of single sign-on user access to multiple web servers, comprising: 

so authenticating a user at a first web server; 

transmitting an encrypted authentication token from the first web server to a second web server, wherein the 
authentication token comprises an expiration time and is digitally signed by the first web server; ' 
authenticating the authentication token at the second web server; and 
allowing the user to conduct a session at the second web server. 



55 



2. The method of claim 1 wherein the first web server and the second web server share a sub-domain. 

3. The method of claim 2 further comprising examining the expiration time of the authentication token at the second 
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web server and allowing the user to conduct a session at the second web server only if the expiration time has not 
passed. 

4. The method of claim 3 wherein the authentication token comprises a cookie 

5 

5. The method of claim 4 wherein transmitting the encrypted authentication token from the first web server to the sec- 
ond web server comprises transmitting the encrypted authentication token from the first web server to the user and 
then from the user to the second web server 

w 6. The method of claim 5 wherein authenticating the user at the first web server comprises receiving a user name and 
password. 

7. The method of claim 6 wherein transmitting the encrypted authentication token from the first web server to a sec- 
ond web server comprises transmitting the authentication token from the first web server to a computer of the user 

is and transmitting the authentication token from the computer of the user to the second web server. 

8. The method of claim 7 wherein the first web server and the second web server comprise a federation of web serv- 
ers. 

20 9. The method of claim 8 wherein authenticating the authentication token at the second web server comprises exam- 
ining the cookie. f 

10. The method of claim 9 further comprising URL encoding the authentication token. 

25 11. The method of claim 10 further comprising URL decoding the authentication token at the second web server. 

12. The method of claim 1 1 further comprising providing a web page to the user having a service selector. 

13. The method of claim 12 wherein the service selector comprises a hyperlink. 

30 

14. The method of claim 13 wherein the hyperlink comprises a URL for the second web server. 

15. A method for single sign-on user access to a federation of web servers, comprising: 

35 allowing a user at a computing device to access a first web server in the federation of web servers via a web 

browser of the computing device; 

authenticating the user with user-provided authentication information, including at least a user identification bv 
the first web server; ' 7 

prompting the user for selection of a functionality offered via at least a second web server; 
40 receiving a selection by the user of the functionality offered via the second web server; 

creating an authentication token for the user including at least the user identification and with a pre-defined 
token expiry by the first web server; 

digitally signing the authentication token by the first web server; 

qualifying the domain attribute of the authentication token with the shared sub-domain name by the first web 
45 server; 

sending the digitally signed authentication token to the web browser of the computing device by the first web 
server; 

redirecting the web browser to the second web server by the first web server; 
sending the authentication token to the second web server by the web browser; 
50 decrypting the authentication token by the second web server; 

checking the pre-defined expiry of the authentication token by the second web server; and 

allowing the user to conduct a session with the second web server if within the pre-defined token expiry. 

16. The method of claim 15 further comprising allowing the user to conduct a session with the first web server. 

17. The method of claim 1 6 wherein the second web server shares a sub-domain with the first web server. 

18. The method of claim 1 7 wherein digitally signing the authentication token by the first web server comprising digitally 
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signing the authentication token using public key encryption. 

19. The method of claim 18 further comprising confirming a match with the digital signature. 

20. A method of single sign-on for multiple web servers, comprising: 

receiving log-in data from a user in a first server; 
providing the user with a service selector; 

receiving an indication that the user selected the service selector; 
constructing an authentication token comprising profile data associated with the user- 
encrypting and signing the authentication token; 
redirecting the user to a second server; 
transmitting the authentication token to the user; 
receiving the authentication token in the second server; 
verifying the authentication token in the second server; and 
allowing the user access to a service provided by the second server. 

21 . The method of claim 20 wherein the authentication token further comprises expiration time data. 

22. The method of claim 21 wherein the authentication token comprises a cookie. 

23. The method of claim 22 wherein the log-in data comprises a user name and password. 

24. The method of claim 23 wherein the service selector comprises a hyperlink. 

25. A system for single sign-on user access to multiple web servers, comprising: 

a means for authenticating a user at a first web server; 

a means for transmitting an encrypted authentication token from the first web server to a second web server 
wherein the authentication token comprises an expiration time and is digitally signed by the first web server- ' 
a means for authenticating the authentication token at the second web server; and 
a means for allowing the user to conduct a session at the second web server.' 

26. The system of claim 25 wherein the first web server and the second web server share a sub-domain. 

27. The system of claim 26 further comprising a means for examining the expiration time of the authentication token at 
the second web server. 

28. The system of claim 27 wherein the authentication token comprises a cookie. 

29. The system of claim 28 wherein the means for transmitting the encrypted authentication token from the first web 
server to the second web server comprises means for transmitting the encrypted authentication token from the first 
web server to the user, and then from the user to the second web server. 

30. The system of claim 29 wherein the means for authenticating the user at the first web server comprises means for 
receiving a user name and password. *' or 

31. The system of claim 30 wherein the means for transmitting the encrypted authentication token from the first web 
seiver to a second web seiver comprises means for transmitting the authentication token from the first web server 
to a computer of the user and means for transmitting the authentication token from the computer of the user to the 
second web server. . ,ure 

32. The system of claim 31 wherein the first web server and the second web server comprise a federation of web serv- 

33. The system of claim 32 wherein the means for authenticating the authentication token at the second web server 
comprises means for examining the cookie. 
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34. The system of claim 33 further comprising a means for URL encoding the authentication token. 

35 * Lte7 tem ° f C,3im ^ C ° mpriSing 3 means for URL decodln 9 < he authentication token at the second web 

36. The system of claim 35 further comprising a means for providing a web page to the user having a service selector. 

37. The system of claim 36 wherein the service selector comprises a hyperlink. 

38. The system of claim 37 wherein the hyperlink comprises a URL for the second web server. 

39. A system for single sign-on user access to a federation of web servers, comprising: 

a means for allowing a user at a computing device to access a first web server in the federation of web servers 
via a web browser of the computing device; servers 

a means for authenticating the user with user-provided authentication information, including at least a user 

identification, by the first web server; y user 

a means for prompting the user for selection of a functionality offered via at least a second web server 

a means for receiving a selection by the user of the functionality offered via the second web server- ' 

a means for creating an authentication token for the user including at least the user identification and with a 

pre-defined token expiry by the first web server; 

a means for digitally signing the authentication token by the first web server- 

thetTweb TeZT d0m9in " ^ token with the *»red «ub-doma.n name by 

LTrstwe" TeT" ^ di9Ha " y aUthentica,ion token <° the «*> browser of the computing device by 

a means for redirecting the web browser to the second web server by the first web server 
a means for sending the authentication token to the second web server by the web browser 
a means for decrypting the authentication token by the second web server 

a means for checking the pre-defined expiry of the authentication token by 'the second web server- and 

a means for al.owing the user to conduct a session with the second web server i, within the pre-defined token 

40. The system of Cairn 39 further comprising a means for allowing the user to conduct a session with ,he first web 

41. The system of claim 40 wherein the second web server shares a sub-domain with the first web server. 

42. The system of claim 41 wherein the means for digitally signing the authentication token by the first web server com 
pnsing means for digitally signing the authentication token using public key encryption. 

43. The system of claim 42 further comprising a means for confirming a match with the digital signature. 

44. A system of single sign-on for multiple web servers, comprising: 

a means for receiving log-in data from a user in a first server; 
a means for providing the user with a service selector; 

a means for receiving an indication that the user selected the service selector- 

a means for constructing an authentication token comprising profile data associated with the user 

a means for encrypting and signing the authentication token; 

a means for redirecting the user to a second server; 

a means for transmitting the authentication token to the user; 

a means for receiving the authentication token in the second server 

a means for verifying the authentication token in the second server- and 

a means for allowing the user access to a service provided by the second server. 

45. The system of claim 44 wherein the authentication token further comprises expiration time data. 
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46. The system of claim 45 wherein the authentication token comprises a cookie. 

47. The system of claim 46 wherein the log-in data comprises a user name and password, 
s 48. The system of claim 47 wherein the service selector comprises a hyperlink. 



w 



15 



20 



25 



30 



35 



40 



45 



50 



55 



14 



DCID: <EP 



1089516A2 I > 



EP 1 089 516 A2 



Customer User 

f 



Customer Client 



10 




Brokerage Finn 
Web Server 




40 



32 

Brokerage Firm Web Site 



— 42 
Bank Web Site 



FIG. 1 



15 



EP1 089 516 A2 



Customer requests 
Bill Payment 



50 



BFWS builds a 
cookie with profile 
data and 
expiration time 
T 



BFWS selects the 
Recipient Name 



52 



54 



BFWS encrypts 
and signs the 
cookie 



BWS 
URL Decodes the 
cookie 



I 

64 



Customer's 
browser connects 
with the BWS and 
sends the cookie 



BFWS sends 
redirect with set- 
cookie 



56 



BFWS 
URLEncodes the 
cookie 



62 



60 



58 



BWS verifies 
decrypts the 
cookie 



66 





No 



BWS re-<Urects 
back to BFWS to 
an error URL 



No 



70 



OK 



78 




Extract profile data 
from cookie and 
begin session 



FIG. 2 



« 



EP 1 089 516 A2 



Web Browser 



AO 



^30 



Brokerage Firm 
Web Server 



.40 



Bank Web Server 




FIG. 3 



OCID: <EP 1089516A2 I > 



17 



EP 1 089 516 A2 



Customer signs 
on to Centra] 
Web Site 
(CWS) 



Customer 
requests 
services from 
CWS menu 



149 



CWS builds a 
cookie with 
profile data and 
expiration time 



150 



T 

152 



CWS selects the 
service provider 
Recipient Name 



CWS encrypts 
and signs the 
cookie 



154 



Service 
provider URL- 
Decodes the 
cookie 


<4 






1 

164 

r 




Service provider 




verifies and 




decrypts the 




cookie 





Customer' $ 
browser connects 
to service provider 
vuSSL«nd sends 
the cookie 



CWS sends 
redirect with 
set -cookie 



162 



X 



156 



CWS URL- 
Encodes the 
cookie 



158 



166 




182 




Service provider 
re-directs back to 
CWS to an error 
URL 



180 



Open User's 
default page 



183 




Yes 



Extract profile 
data from 
cookie and 

begin session 



178 



Create ID and 
user employer- 
specific default 
profile 



181 



FIG. 4 



18 



(19) 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 




(12) 



EP 1 089 516 A3 

EUROPEAN PATENT APPLICATION 



(88) Date of publication A3: 

28.08.2002 Bulletin 2002/35 

(43) Date of publication A2: 

04.04.2001 Bulletin 2001/14 

(21) Application number: 00203266.2 

(22) Date of filing: 20.09.2000 



(51) mtci7: H04L 29/06, G06F 1/00 



(84) Designated Contracting States: 

AT BE CH CY DE DK ES Fl FR GB GR IE IT LI LU 
MCNLPTSE r 
Designated Extension States: 
AL LT LV MK RO SI 

(30) Priority: 24.09.1999 US 155853 P 

(71) Applicant: Citicorp Development Center, Inc. 
Los Angeles, California 90066 (US) 

(72) Inventors. 

♦ Grandcolas, Michael L. 
Santa Monica, CA 90405 (US) 

• Law, France 

Los Angeles, CA 90034 (US) 



(54) 



• Doshi, Ashwin 
Cerritos, CA 90703 (US) 

• Williams, Michael 
Thousand Oaks, CA 91362 (US) 

• Jang, Yeona 
Princeton, NJ 08540 (US) 

• Merschen, Toni 

White Plains, NY 10605 (US) 

• Pan, Jack 

Rowland Heights, CA 91748 (US) 

(74) Representative: Hynell, Magnus 
Hynell Patenttjanst AB, 
Patron Carls vag 2 
683 40 Hagfors/Uddeholm (SE) 



Method and system for single sign-on user access to multiple web servers 



(57) Methods and systems for single sign-on user 
access to multiple web servers are provided. A user is 
authenticated at a first web server (e.g., by user name 
and password). The first web server provides a web 
page to the user having a service selector (e.g., a hy- 
perlink comprising the URL of a second web server of- 
fering the service indicated by the selector). When the 
user activates the service selector, the first web server 
constructs and transmits an encrypted authentication 



token (e.g., a cookie) from the first web server to a sec- 
ond web server via the user client. The first and second 
web servers share a sub-domain. The authentication to- 
ken comprises an expiration time and is digitally signed 
by the first web server and is authenticated at the sec- 
ond web server. Upon authentication, the second web 
server allows the user to conduct a session at the sec- 
ond web server. 



CO 
< 
CD 

to 

CO 

o 

CL 
LU 



Printed by Jouve. 75001 PARIS (FR) 



5OOCI0: <EP 1069S16A3 i > 



EP 1 089 516 A3 




European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Number 

EP 00 20 3266 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with indication, where appropriate, 
of relevant passages 



J. S. PARK: "Secure Attribute services on 
the Web" 'Online! 

June 1999 (1999-06) , GEORGE MASON 
UNIVERSITY , FAIRFAX, VIRGINIA XP002190891 
Retrieved from the Internet: <URL: 
h t tp : //www . 1 i s t . gmu . edu/d i s s er t/d i s s - jean 
pdf> 'retrieved on 2002-02-21! 
Chapter 4, 
Figures A.1-A.10, 



ANSELM BAIR0-SMITH (ABAIRDeWWW18.W3.0RG)- 
"Re: URLEncoder, where is the URLDecoder? 

INTERNET NEWSGROUP , 'Online* 

29 April 1996 (1996-04-29), XP002191148 

comp. lang. java 

Retrieved from the Internet: 
<URL:http: //groups . google. com/> 
'retrieved on 2002-02-21! 

* the whole document * 

EP 0 913 789 A (SUN MICROSYSTEMS INC) 
6 May 1999 (1999-05-06) 

* claims 1,2* 

J00N S. PARK : "A Secure Cookie Recipe for 
Electronic Transactions" 
1999 U.S. -KOREA CONFERENCE (UKC) ON 
SCIENCE, TECHNOLOGY, ENTREPRENEURSHIP , AND 
LEADERSHIP, , 'Online! 

12 - 14 August 1999, XP002191149 
UCLA, Los Angeles, California 
Retrieved from the Internet: 

<URL: http://citeseer.nj. nec.com/park99secu 
recookie.html> 'retrieved on 2002-02-21! 
the whole document * 



Relevant 
to claim 



1-9, 
15-23, 
25-33, 
39-47 



10-12, 
24, 

34-36,48 

10-12, 
34-36 



24,48 



1-9 



-/— 



The present search report has boon drawn up for all claims 



P bee of soarch 

THE HAGUE 



Oah* d oomptatioo of the search 

28 June 2002 



15-33, 
39-48 



CATEGORY OF CtTEO DOCUMENTS 



CLASSIFICATION OF THE 
APPLICATION <lnt-CI.71 



H04L29/06 
G06FI/00 



TECHNICAL FIELDS 
SEARCHED (lnt.CI.7) 



H04L 



Bertolissi , E 



X : particularly Levant iJ taken alone 

Y : particularly relevant it combined with another 

document ot the same category 
A : technological background 
O : non -written disclosure 
P : intermediate document 



T : theory or principle underlying the invention 

: !^^,? al docun * fnl - bu - Pushed on. or 
arner the Wing date 

O : document cited in the application 

L : document dted tor other reasons 



CID: <EP 



EP 1 089 516 A3 




European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Number 

EP 00 20 3266 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with indication, where appropriate. 
of relevant passages 1 



Relevant 
to claim 



CLASSIFICATION OF THE 
APPLICATION (tntCt.7) 



WO 99 20060 A (DSC TELECOM LP) 

22 April 1999 (1999-04-22) 

* page 34, line 1 - page 35, line 



15-33, 
39-48 



5 * 



TECHNICAL FIELDS 
SEARCHED (lnt.CI.7) 



The present search report has been drawn up for all claims 



Pbee of s«arcf> 



THE HAGUE 



Oirte of compVrtbn of if*© search 

28 June 2002 



Bertolissi, E 



CATEGORY OF CITED DOCUMENTS 

X : particularly relevant If taken alone 

Y ; particularly relevant If combined with another 

document erf the same category 
A : technological background 
O : non-written disclosure 
P : irrtermfldwta document 



T : theory or principle underlying the Invention 
E : earfer patent document bat published on. or 

after the filing date 
D : document died in the application 
I : document cited lor other reasons 

& : member of the same patent family, corresponding 
document 



»:iD: <EP 



1089516A3 I > 



EP1 089 516 A3 



ANNEX TO THE EUROPEAN SEARCH REPORT 

ON EUROPEAN PATENT APPLICATION NO. EP 0 0 20 3266 



Z?; iS ^ ne t ^ StS th ° ?* {on } membefs relating to the patent documents ched «n the above -mentioned European search renort 

The members are as contained in the European Patent Office EDP flte on European searcn report 

The European Patent Office is in no way liable for these particulars which a/e merely given for the purpose of information. 

28-06-2002 



Patent document 
cited in search report 



Publication 
date 



Patent family 
member(s) 



EP 0913789 



06-05-1999 



EP 
JP 



0913789 A2 
11265411 A 



W0 9920060 



22-04-1999 



US 
AU 
EP 
W0 



6243451 Bl 
9514398 A 
1020088 Al 
9920060 Al 



Publication 
date 



06-05-1999 
28-09-1999 



05-06-2001 
03-05-1999 
19-07-2000 
22-04-1999 



oi For more details about this annex see Official Journal of the European Patent Office, No. 12/82 



4 



1089516A3 1 



